home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / Makefile.README < prev    next >
Makefile  |  1994-08-01  |  6KB  |  148 lines
  1.  
  2.                       ~4Dgifts/toolbox/Makefile.README
  3.  
  4.  
  5.      In the wacky world of IRIX 5.x the toolbox janitor has learned of some
  6.      useful tidbits to pass on:
  7.  
  8.  
  9.      --> what "Warning: Quickstart not set for..." means, when compiling.
  10.          To start with, in IRIX 5.2, they forgot to change the lines in
  11.      /usr/include/make/commondefs from:
  12.  
  13. # Note: To turn off -quickstart_info for specific Makefile add:
  14. #               LD_QUICKSTART_INFO=
  15. LD_QUICKSTART_INFO=-quickstart_info
  16.  
  17.          to be what was intended:
  18.  
  19. # Note: To turn on -quickstart_info for specific Makefile add:
  20. #               LD_QUICKSTART_INFO=-quickstart_info
  21. LD_QUICKSTART_INFO=
  22.  
  23.          but wasn't remembered tuntil it was too late to be changed.  Since 
  24.      "-quickstart_info" is still active, there are many cases where the
  25.      compilers will appear to be barking about something, that in fact 
  26.      is not actually a "loss" in the performance sense of the word.  
  27.  
  28.      Picking up from a thread on an internal sgi news group about all
  29.      this:
  30.  
  31.     Subject: Re: why do I get "Warning: Quickstart not set for..."
  32.     | >     Warning: Quickstart not set for wipe_split since you are using different versions of libgl.so
  33.     | 
  34.     | It's a long story, but the short version of it is that you have more 
  35.     | than one component in your link that depends on libgl.so (say, your 
  36.     | program and one of your other DSOs), and that they were created 
  37.     | against different versions of libgl.so.
  38.     | 
  39.     | Walk down your library list for your link, and run "elfdump -Dl" on 
  40.     | each of them, looking for "libgl.so" in the output.  Compare the 
  41.     | timestamp on them with the timestamp in the libgl.so on your system 
  42.     | (obtained using "elfdump -L /usr/lib/libgl.so").
  43.  
  44.     *By definition* any system with graphics has a different libgl.so than 
  45.     all the other DSO's were linked against, because that is the server 
  46.     libgl.so in the build tree.  This is one of the issues that the 
  47.     performance team grappled with, and ignored, waiting for requickstart.  
  48.     Fortunately, libgl is usually one of the last libraries in the library 
  49.     list, and only that library and the ones following it fail to 
  50.     quickstart;  the ones before it will.
  51.  
  52.     However, you should *NOT* be getting the complaint, unless you are using
  53.     the commondefs stuff, because that warning was supposed to be turned off
  54.     in the 5.2 MR compilers, by default.
  55.  
  56.     - - - - - - - - - - - - - - - -- - - - - - -
  57.  
  58.     | It's a long story, but the short version of it is that you have more 
  59.     | than one component in your link that depends on libgl.so (say, your 
  60.     | program and one of your other DSOs), and that they were created 
  61.     | against different versions of libgl.so.
  62.  
  63.     If a DSO was linked with libgl.so without the DELAY option by, for 
  64.     example, specifying libgl in LLDLIBS, that is a bug in the Makefile 
  65.     for that DSO.  We have to specify all dependent DSOs, except the 
  66.     libgl.so DSO, in LLDLIBS when we build our DSOs if we want the programs 
  67.     linked with our DSOs to quickstart.  When they introduced the DELAY 
  68.     option, I think you could link your DSO with libgl.so with the DELAY 
  69.     option.
  70.  
  71.     I checked DSOs on a machine, and found two DSOs that are linked with 
  72.     libgl with DELAY, and one without DELAY.  I think that the ones with 
  73.     DELAY are O.K., but that the other one needs to be fixed: could _____
  74.     please confirm that, before I open bug reports.
  75.  
  76.     libSgm.so:
  77.         libgl.so     Apr  4 01:28:31 1994 0x1ce762ea DELAY sgi1.0
  78.  
  79.     libSgw.so:
  80.         libgl.so     Apr  4 01:28:31 1994 0x1ce762ea DELAY sgi1.0
  81.  
  82.     libil.so:
  83.         libgl.so     Apr  4 01:28:31 1994 0x1ce762ea  NONE sgi1.0
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.      --> In IRIX5, don't use _s when specifying libraries to link with.
  91.      Entering the brave new world of dso's, it is important to 
  92.      remember that shared libraries are again, a thing of the past.  
  93.      For compiling, any library linked in with a trailing "_s" is 
  94.      meaningless, because we no longer are working with the rules 
  95.      set up by SVR4.  AT&T USL SVR3 created and used the -lc_s 
  96.      terminology, and when they created SVR4 (which is what IRIX 5 
  97.      works like), AT&T USL abandoned the "_s" way of specifying 
  98.      shared libraries and went back to the old style, "-lc,".  True, 
  99.      one *can* still compile with _s, but this specifier simply gets 
  100.      munged by the linker (if not before) and tossed out, so that 
  101.      whether its an archive or a dso, the linker will do the right 
  102.      thing.
  103.      Since v4.0, the toolbox janitor has attempted to expunge all 
  104.      "_s" library names from Makefiles in the src and lib subtrees.  
  105.      If you find anyplace where they still exist, please let me know
  106.      at dave@sgi.com or 415/390-3556.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.      --> In IRIX5, libsun.a is no more.     
  114.      Don't link with -lsun in IRIX 5--there is no longer any such
  115.      library, even thought there is still a stub in /usr/lib/libsun.a
  116.      so older Makefiles won't break.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.      --> All Makefiles in the src tree now work with commondefs' VLDOPTS.
  124.      In case yer as ignorat as the toolbox janitor tends to be of the 
  125.      power of /usr/include/make/{commondefs,commonrules}, please notice 
  126.      all references to "-s" for generating stripped binary files have
  127.      been expunged from the Makefiles in the src subtree.  In concert
  128.      with this the proper usage of $(LDFLAGS) on the load/link line has 
  129.      been corrected in Makefiles where $(LLDLIBS) was used previously
  130.      (always be sure you use $(LDFLAGS) on the loader line--this 
  131.      enables one to "hook on" all kinds of dynamic flags settings at
  132.      make/compile-time and avoid the clunkiness of having "hard-wired" 
  133.      flags statically fixed inside the Makefiles).  From all this one 
  134.      can now build whatever portion of the src subtree one wants to as 
  135.      stripped binaries by using the commondefs Loader flag, VLDOPTS 
  136.      and setting it equal to "-s" thusly:
  137.      
  138.          % make VLDOPTS=-s
  139.  
  140.      At this point all binaries generated will be stripped.  On v4.0,
  141.      about 98-plus percent of binaries in the the src subtree are 
  142.      stripped and were generated by taking advantage of commondef's 
  143.      variable loader flag.  (The only actual documentation on commondefs
  144.      and commonrules exists as comments in the files themselves, but as
  145.      with all such things, spending a little time reading/acquainting
  146.      oneself with these tools can save a LOT of time later on.)
  147.  
  148.